home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-wada-packet-forwarding-00.txt
< prev
next >
Wrap
Text File
|
1993-08-20
|
70KB
|
1,768 lines
Mobile IP Working Group Hiromi Wada
INTERNET DRAFT Tatsuya Ohnishi
Matsushita Electric Industrial Co., Ltd.
Brian Marsh
Matsushita Information Technology Laboratory
July 1993
Packet Forwarding for Mobile Hosts
Abstract
This memo describes a new protocol for mobile internetworking:
the Internet Packet Transmission Protocol (IPTP). IPTP
provides packet forwarding and host location functions that
make mobility transparent to all protocols above IP. IPTP
specifies control messages between the networking software on
mobile hosts and a special Packet Forwarding Service.
Backward compatibility is provided by requiring no
modifications to stationary hosts or internetwork routers. To
reduce overhead, IPTP provides for lazy propagation of
location updates. To enhance performance, routes adapt as
mobile hosts move.
Status of this memo
This document describes an approach to transparent mobile
internetworking. This RFC requests discussion and suggestions
for improvements. Distribution of this memo is unlimited. It
expires on January 2, 1994. Please respond with comments to the
mobile-ip@parc.xerox.com mailing list.
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force(IETF), its
Areas, and its Working Groups. Note that other groups may also
distribute working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted
by other documents at any time. It is not appropriate to use
Internet Drafts as reference material or to cite them other than
as a ``working draft'' or ``work in progress.''
Please check the 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
current status of any Internet Draft.
1 Introduction
Expires 2 January 1994 [Page 1]
Internet-Draft Packet Forwarding July 1993
1.1 Goals
Our aim is to support a computing environment where hosts can
communicate with each other continuously as they migrate across
networks. We describe an IP-level solution designed to minimize the
impact on existing protocols and applications. Our solution
provides packet forwarding and host tracking to allow IP packets to
find their way between mobile and non-mobile hosts.
From a practical point of view, we have two goals: backward
compatibility and performance. To provide backward compatibility
we try to minimize the amount of software that must be modified.
First, IPTP requires no changes to router software.
Second, it requires no changes at all to the software of stationary
hosts. Finally, it requires no changes to mobile hosts above the
network layer.
To enhance performance, we need to minimize the overhead added to
each forwarded packet, and to make migration as inexpensive as
possible. Per-packet overhead is due to encapsulation and any
additional hops that are added to a route. Host migration, or
handoff as other proposals refer to it, has costs associated with
the propagation of location information. IPTP requires
encapsulation only for packets sent to the mobile host. Packets
from the mobile host have no additional overhead. IPTP also
provides adaptive routing to elminate unnecessary hops between
communicating hosts. To cut down on the overhead of migration,
IPTP provides lazy propagation of host location information,
reducing the number of messages sent when a host moves.
1.2 Basic Concepts
IPTP assumes three active entities: Mobile Hosts (MH), Stationary
Hosts (SH), and Packet Forwarding Servers (PFS). IPTP is the
protocol used between these entities to implement the functions of
MH location tracking and packet forwarding. An MH is a machine
that can roam between networks. We assume that the kernel on this
machine can be modified, but that protocols above IP will not be
changed. In addition, we assume that applications will not be
changed to account for roaming. Next, an SH is a machine that does
not move. In the worst case we assume that no software can be
changed. When such modifications are possible, IPTP specifies
important performance enhancements that can be made. Finally, a PFS
is a user-level server that runs on an SH (We assume that the
kernel allows user-level programs to receive arbitrary packets,
e.g., through a facility such as NIT in SunOS Release 4.0).
It forwards packets for roaming MHs. In addition, it provides the
primary copy of MH location information for any MHs for which it is
the home PFS.
Expires 2 January 1994 [Page 2]
Internet-Draft Packet Forwarding July 1993
The basic idea is as follows. An MH has two addresses: a home
address and a temporary address. The home address is a legitimate
IP address on a subnet distinguished as the home network for the
MH. Home addresses are statically assigned and never change.
A temporary address is assigned as the
MH moves between networks. Packets are sent to an MH using its
home address. When an MH has moved away from its home network,
IPTP uses the temporary address to forward packets to the new
location of the MH. IPTP is designed to maintain the mappings
between an MH's home and temporary addresses, and to forward
packets to roaming MHs.
Packets are forwarded by encapsulating them in special IPTP
packets. IPTP provides two operational modes
whose use depends on whether the SH can be modified or not:
forwarding mode and autonomous mode. Forwarding mode allows an
unmodified host to communicate with an MH. Packets sent to a
roaming MH are transmitted via standard IP but are intercepted by a
PFS. The PFS then encapsulates the packets and forwards them to
the MH's current temporary address. In autonomous mode, the packet
forwarding facility is built directly into the networking software
of the SH. A packet sent to the MH is encapsulated in an IPTP
packet whose destination address is the MH's temporary address.
The PFS is removed from the transmission path except for tracking
MHs. MH-to-MH communication works exactly the same way as
SH-to-MH communication.
We have two kind of PFSs. One is a home PFS, and the other is an
Autonomous Supporter(AS) PFS. The home PFS is located on a home
network of MHs. The PFS is responsible for forwarding packets
to an MH's temporary networks and for managing location information.
The AS are located on a new network that an MH has visited. After
the MH again migrates to another network, the AS forwards packets
destined for the MH to its current network.
1.3 Overview
This document is organized as follows. In Section 2 we discuss how
mobile hosts are addressed. In Section 3 we detail how packet
forwarding is done, both for backward compatibility and performance.
In Section 4 we focus on how location information is maintained. In
Section 5 we present the details of the IPTP protocol. In Section 6
we describe important implementation issues.
2 Addressing
Each MH has two addresses: a home address and a temporary address.
Expires 2 January 1994 [Page 3]
Internet-Draft Packet Forwarding July 1993
The "home" address distinguishes the network from which the MH
originates. The home address remains the same even while the MH is
roaming. The network part of the home address is equal to the home
network address. The notion of a home is useful because it
provides an easily found source of reliable information about a
roaming MH. In particular, a PFS located on an MH's home network
is responsible for tracking its whereabouts at all times. That PFS
is also responsible for forwarding packets sent to a roaming
MH's home address.
The temporary address reflects the current real location
of the MH (we also refer to it as the "real address"). The network
part of the address is equal to the network address where the MH
currently lives. A temporary address changes every time the host
migrates to a new network. The exact process of assigning
temporary addresses is beyond the scope of this document.
Applications address an MH using its home address, regardless of its
location. This is true both for applications running on the MH and
for applications on other machines that must communicate with the MH.
To send data to an MH, a host builds an IP packet whose destination
address is the home address of the MH. The IP packet is then
encapsulated in an IPTP packet whose destination address is the
current temporary address of the MH. The packet is then delivered to
the MH using existing routing mechanisms. An MH receiving an
encapsulated packet decapsulates it to yield the original IP packet.
Because the temporary address of an MH is assigned dynamically when
the MH visits a network, encapsulated packets might mistakenly be
sent to a temporary address that has been reassigned to another MH.
To filter out such packets, each encapsulated packet is tagged with
the home address of the destination MH. Since each MH has a unique
home address, it is possible to distinguish packets that should not
actually be delivered. An encapsulated packet is accepted only if
the temporary and home addresses match those of the receiving host.
3 Packet Forwarding
In this section, we describe packet forwarding in detail. As
described in Section 1.2, packet forwarding is done in one of two
modes: forwarding mode and autonomous mode. In forwarding mode,
the SH is unmodified and packets are forwarded by a PFS. In
autonomous mode, packet forwarding is performed by the sending
host. Both modes can co-exist in one environment.
3.1 Forwarding Mode
In forwarding mode, packet forwarding for an MH is performed by a PFS
on the MH's home network. In Figure 1 we consider communication
Expires 2 January 1994 [Page 4]
Internet-Draft Packet Forwarding July 1993
between an SH and an MH.
+--------+
| |
+---> | PFS | ---+
(1) SH to MH | | | |(2)Packet Forwarding
| +--------+ | (normal packet(1) is
| | encapsulated in it)
+--------+ | | +--------+
| | ---+ +---> | |
| SH | | MH |
| | <--------------------------- | |
+--------+ (3) normal packet +--------+
Figure 1. Forwarding Mode
(1) SH to MH - An SH sends a packet to an MH specifying the MH's home
address. The packet is routed to the MH's home network where it
is intercepted by a PFS. Packet interception is arranged by the
PFS either by using some sort of promiscuous mode or by arranging
with local gateways for packets to be routed to the SH on which
the PFS is running.
(2) Packet Forwarding - The PFS encapsulates the packet sent in (1)
into a "Packet Transmission" packet (the exact format is
described in Section 5.2). The destination address in the IPTP
message is the temporary address of the MH. The PFS maintains a
mapping between the home address and the temporary address by
the IPTP protocol. This location information management is
described below.
When the MH receives the "Packet Transmission" message, its
IPTP layer decapsulates the IP packet it contains. From the
perspective of applications running on the MH, the MH appears
to still reside on its home network.
(3) MH to SH - The packet decapsulated from the "Packet
Transmission" message contains the IP address of the SH in its
source address field. The MH sends a reply packet directly to
the SH using standard IP. The source address used for the
reply packet is the MH's home address. Because reply packets
are standard IP packets, they are routed using normal IP
routing mechanisms. We assume that the MH dynamically acquires
such routing information through a protocol such as DHCP[2].
3.2 Autonomous Mode
Autonomous mode allows an SH to transmit packets directly to an MH,
without relaying them via a PFS. The packet routes that result can
Expires 2 January 1994 [Page 5]
Internet-Draft Packet Forwarding July 1993
be significantly shorter. An autonomous mode connection has two
key requirements. First, the SH must have been modified to do its
own packet forwarding. Second, the MH must be able to find a PFS
on its current network to act as an AS.
An AS acts like a home PFS in the following way:
if an MH migrates away from that network, the AS
will intercept packets sent to it, and forward them to the MH's new
address.
3.2.1 SH Transmission
In this mode, packet forwarding is performed directly by the
SH, instead of by the PFS. Figure 2 illustrates this
case. The SH maintains a mapping between the home address and the
temporary address of the target MH. In this respect the
functionality added to the networking software of the SH is
similiar to that added to the PFS. The difference is
in how location information is propagated. Location updates are
sent by the MH to its home PFS, a PFS acting as an autonomous
supporter and an modified SH. If an SH initiates communication with
an MH after the MH has migrated, it receives updates lazily when it
uses stale addresses to send packets to the MH. If not, the peer MH
sends its current temporary address to the SH before the MH sends its
first packet to the SH after its migration. The SH mappings can be
viewed as a cache of the primary copy maintained by the home PFS.
Details of location information management is described in the
Section 4.
(1) SH to MH
(SH's normal packet
+--------+ is encapsulated) +--------+
| | --------------------------> | |
| SH | | MH |
| | <-------------------------- | |
+--------+ (2) MH to SH +--------+
Figure 2. Autonomous Mode
(1) SH to MH - The SH sends a packet directly to the MH.
Applications on the SH use the MH's home address. IPTP
software on the SH encapsulates the packet into a "Packet
Transmission" message and sends it to the MH using the MH's
current temporary address. On receiving the packet, the MH's
IPTP software decapsulates the original IP packet and passes it
to the appropriate higher-level protocol.
(2) MH to SH - The MH sends a packet directly to the SH using
standard IP. This is the same as in the forwarding mode above.
Expires 2 January 1994 [Page 6]
Internet-Draft Packet Forwarding July 1993
3.2.2 Autonomous Supporter Transmission
An AS will forward packets destined for an MH that is no longer
present on the local network. It knows the MH's temporary address
there, because it was notified it by "Ping Autonomous Supporter"
message when it visited the network. It will also get the MH's
current temporary address, because it will be notified it by "MH
Location Information" message when the MH will visit a new network.
Recall that the AS is a local PFS that has agreed
to provide support for autonomous mode communications with visiting
MHs. When the MH migrates to a new network, it notifies the AS.
The AS will then begin to look for packets destined for the MH's
local IP address (the temporary one assigned when the MH first
arrived). If the AS knows the current temporary address of the MH,
it will forward any packets it intercepts. If it doesn't know the
current address of the MH, the packets are sent to the home PFS,
which should have the MH's current location. The home PFS address
is contained in the IPTP header of the intercepted packet.
Figure 3 illustrates this case.
(current network) (home network)
+====+ (3) Packet Forwarding +=====+
| MH |<-----------------------------| home|
+----->| |<------+ +-->| PFS |
| +====+ |(2a) Packet | +=====+
| | Forwarding |
| | +----------------+
migration | | (2b) Packet Forwarding
| | |
| (Ghost) | |
| +----+ +=====+ +====+
| | | | PFS |<-------------| SH |
+---------| | | | (1) SH to MH | |
+----+ +=====+ +====+
(previous network)
Figure 3. Forwarding mode by an autonomous supporter PFS
(1) SH to MH - The SH in autonomous mode sends a packet directly to
the temporary address of the MH, although the MH is not at the
temporary address any longer.
(2) Packet Forwarding by Autonomous Supporter - If the autonomous
supporter PFS learns the current address of the MH
through the mechanism described in Section 4,
Expires 2 January 1994 [Page 7]
Internet-Draft Packet Forwarding July 1993
it forwards the packet to the current temporary
address(2a). If not, it forwards the packet to the home
address(2b). When forwarding, the PFS does not encapsulate the
packet because it is already encapsulated. Instead, it
decrements the counter field in the IPTP header by 1 and if the
value is 0, the PFS discards the packet.
(3) Packet Forwarding - This takes place only when preceded by (2b).
The home PFS forwards the packet to the current temporary address
of the MH. Forwarding process is the same as (2) above (counter
decrement and no encapsulation).
4 Location Information Management
In this section we describe how IPTP is used to maintain location
information. A home PFS maintains the primary copy of location
data for its local network. When an MH migrates, it transmits its
new configuration information to its home PFS. This data includes
the MH's new temporary address and whether there is an Autonomous
Supporter on the new network. The home PFS is then responsible
for propagating the data to all concerned hosts. This data may be
cached by MHs, SHs, and autonomous supporters (ASs). PFSs need it
to support packets transmitted in Forwarding Mode. MHs and SHs
need it when communicating in Autonomous Mode. Below, we describe
how updates are first sent when an MH migrates and later propagated
to other MHs, SHs, and ASs.
4.1 MH Migration/PFS Notification
When an MH moves to a new network, it transmits new configuration
information to its home PFS and its previous AS. Notification to
the home PFS is for redirecting packets sent in Forwarding
Mode. Notification to the AS is for redirecting packets sent in
Autonomous Mode. Figure 4 describes how configuration information
is collected and distributed.
Expires 2 January 1994 [Page 8]
Internet-Draft Packet Forwarding July 1993
(current network)
Ping Autonomous Supporter (home network)
+====+ (1) +=====+ +=====+
| MH |----->| PFS | | home|
+-->| | | | +-->| PFS |
| +====+ +=====+ | +=====+
| || |
| |+------------------------------------+
| | (2) MH Location Information
| |
| +-------------------------+
| |(3) MH Location Information
| (Ghost) v
| +----+ +=====+
migration | | | PFS |
+------------------| | | (AS)|
+----+ +=====+
(previous network)
Figure 4. Location information distribution
(0) The MH is assigned a temporary address using a protocol such
as DHCP.
(1) Autonomous Supporter -- The MH tries to find a PFS which
can support autonomous mode in the new network. The MH
broadcasts a "Ping Autonomous Supporter" message. If
any PFS responds, the MH will transmit packets in autonomous
mode. When a PFS receives a "Ping Autonomous Supporter", it
sends to the sender a reply message with an autonomous flag
which indicates whether it supports the mode or not. A PFS
supporting Autonomous Mode registers the MH in a list of
visiting MHs.
(2) MH Location Information - The MH sends an "MH Location
Information" message to a PFS on its home network. This message
carries the home and temporary addresses of the MH, an
autonomous flag which indicates whether the MH can communicate
in autonomous mode or not, and the address of the PFS which
responded to the "Ping Autonomous Supporter" message.
When a PFS in the home network receives an "MH Location
Information" message, it returns an acknowledgement to the MH,
and updates its mapping for the home address of the MH.
(3) MH Location Information to a Previous PFS - The MH also sends an
"MH Location Information" message to an AS (if any) on its
previous network. If the MH has not just migrated from its home
network and if it was operating in autonomous mode on the
Expires 2 January 1994 [Page 9]
Internet-Draft Packet Forwarding July 1993
previous remote network, there must have been an Autonomous
Supporter on that network. Hence, the MH sends it an "MH
Location Information". When the AS receives the "MH Location
Information" message, it acknowledges the message and flags its
mapping (if any) for the MH. The flag indicates that the MH has
migrated, and means that the AS may delete the MH's entry if
necessary. After that, the AS starts looking for packets
destined for the MH's obsolete temporary address.
4.2 Autonomous Sender Notification
Notifying the home PFS only takes care of packets sent in forwarding
mode. If a host can use autonomous mode to communicate with an MH
which is migrating from its home network to another network,
and if an AS in the new network works for the MH, then the host
should change to autonomous mode. This notification is described in
Section 4.2.1.
If a host is using autonomous mode to communicate with the MH,
there are two possibilities for how to distribute the MH's
current temporary address to the host.
In one case, the host has sent a "Packet Transmission" message
to the network previously occupied by the MH.
An AS in that network works on behalf of the MH.
If the AS knows the MH's current temporary
address, it will inform the host of it.
This case is described in Section 4.2.2.
In the other case, the MH has sent a
"MH Location Information" message to the host prior
to re-starting communication after migration.
This case is described in Section 4.2.3.
In both
cases, IPTP provides lazy notification by waiting until a message is
sent to the host.
4.2.1 Packets to the Home Address
A host that communicates with an MH that has migrated may address
its packet to the home address of the MH. If the sending host
supports autonomous mode, then its location tables must be updated
to reflect the new location of the MH. Figure 5 depicts how this
update procedure takes place.
Expires 2 January 1994 [Page 10]
Internet-Draft Packet Forwarding July 1993
+====+
+-----| SH |-----+
| | |<--+ |
(4)| +====+ | |(1) Normal
Packet| MH(3) | | Packet
Transmission| Location| | Transmission
| Information| |
| | | +=====+
+====+ | | +---->| home|
| MH |<---+ +-------| PFS |
| |<------------------------- +=====+
+====+ (2)Packet Forwarding
(current network) (home network)
Figure 5. Packets to the Home Address
(1) Normal Packet Transmission - The SH sends a normal IP packet to
the MH's home address.
(2) Packet Forwarding - The home PFS picks up the packet,
encapsulates it within an IPTP "Packet Transmission" message,
and sends it to the MH's current temporary address.
(3) MH Location Information - If the MH has moved to a network that
supports autonomous mode then the home PFS attempts to notify
the SH that autonomous mode communication is possible. If the
SH is capable of autonomous mode communication, when it receives
the "MH Location Information" message, it caches the MH's new
temporary address, and enters autonomous mode for all packets
destined for the MH.
(4) The SH can now send packets to the MH without an intervening hop
through the PFS.
4.2.2 Packets from an AS
If an SH using autonomous mode is communicating with an MH which
is not located in its home network, an AS must be in the network
where the MH exists. If the MH has migraterd to a new network and
if another AS exists there, the SH can continue to communicate
with the MH using autonomous mode. The AS in the previous network
forwards "Packet Transmission" messages destined for the MH to its
current temporary address and informs the SH of the address.
Figure 6 illustrates this case.
Expires 2 January 1994 [Page 11]
Internet-Draft Packet Forwarding July 1993
(current network) (home network)
+====+ +=====+ +=====+
| MH | | PFS | | home|
| |<-+ | (AS)| | PFS |
+====+ | +=====+ +=====+
^ ^ |
| | +----------------------------+
| | |
| +--------+(2) Packet |(4) Packet
migration | Transmission | Transmission
| | |
| | |
(Ghost) | (3) Location |
+----+ +=====+ Information +====+
| | | PFS |----------------->| SH |
| | | (AS)|<-----------------| |
+----+ +=====+ (1) Packet +====+
(previous network) Transmission
Figure 6. Packets from an AS
(1) Packet Transmission - The SH using autonomous mode sends "Packet
Transmission" message to the previous temporary address of the
MH.
(2) Packet Transmission - The AS in the previous network forwards it
to the current temporary address of the MH.
(3) Location Information - The AS in the previous network informs
the SH of the current temporary address of the MH.
(4) Packet Transmission - The SH sends subsequent packets to the
MH's current temporary address.
4.2.3 Packets from a Migrated MH
Before a migrated MH initiates communication with an SH, the MH
sends an "MH Location Information" message to the SH. If the SH
supports autonomous mode, it extracts the MH's current temporary
address. Therefore, when the SH responds a packet sent by the MH,
it can send the packet directly to the MH via normal IP routing
instead of through a PFS. Figure 7 illustrates this case.
Expires 2 January 1994 [Page 12]
Internet-Draft Packet Forwarding July 1993
(1) MH Location Information
+-------------------------------------+
| |
v |
+-------+ (2) Normal IP Packet +-------+
| | <--------------------------- | |
| SH | | MH |
| | ---------------------------> | |
+-------+ (3) Packet Transmission +-------+
Figure 7. Packets from a Migrated MH
(1) MH Location Information - The MH informs the SH of its own
current temporary address, before it starts communicating with
the SH.
(2) Normal IP Packet - The MH sends a normal IP packet to the SH.
(3) Packet Transmission - The SH can encapsulate packets to the MH
into the "Packet Transmission" messages.
4.3 Packets to an Obsolete Temporary Address
Figure 8 illustrates what happens if a PFS acting as an autonomous
supporter (AS) receives a packet destined for an MH that has
already left its network. The AS must encapsulate and forward the
packet. More importantly, however, it must notify the sending host
of the MH's new address.
Expires 2 January 1994 [Page 13]
Internet-Draft Packet Forwarding July 1993
(current network) (home network)
+====+ +=====+
+->| MH |<---------+(4b) | home|
| | |<--+ |Subsequest | PFS |---+(5)
| +====+ | |Packet +=====+ |MH
| | |Transmission ^ |Location
migration |(2) +---------+ | |Information
| |Packet | | |
| |Forwarding | |(4a) |
| | | |Subsequest
| | | |Packet
(Ghost) | (3)MH Location | |Transmission
+----+ +=====+ Information +---+====+ |
| | | PFS |----------------->| SH |<-+
| | | (AS)|<-----------------| |
+----+ +=====+ (1)Packet +====+
(previous network) Transmission
Figure 8. Packets to an Obsolete Temporary Address
(1) Packet Transmission - The SH sends a "Packet Transmission"
message to the MH's old temporary address. The autonomous
supporter for the MH's old temporary address will intercept the
packet. It knows that the MH is gone because it received a "MH
Location Information" message as described in Section 4.1,
paragraph 3.
(2) Packet Forwarding - The AS may attempt to forward the packet to
the MH if the MH's new temporary address is still in its cache.
However, the AS is not required to maintain the new address
of the MH. If it is not in the cache, the AS knows only that
it has gone. If so, the packet is instead forwarded to the
home PFS for correct rerouting.
(3) MH Location Information - The AS must now notify the SH that
it has an out of date address for the MH. It therefore sends
to the SH an "MH Location Information" message. The AS
includes the MH's new address if possible, allowing subsequent
packets to be routed directly to the MH without going through
the home PFS. If the AS does not know the MH's new address
then the address field is set to NULL, indicating that the SH
should route packets to the MH's home network where they are
picked up by the home PFS.
(4) Subsequent Packet Transmission(SH to MH) - The SH knows that its
mapping for the MH is stale. If no new address for the MH was
received in (3), then it will transmit subsequent packets to
the MH's home network for processing by the home PFS (4a).
Expires 2 January 1994 [Page 14]
Internet-Draft Packet Forwarding July 1993
Otherwise, it will transmit subsequent packets to the new
temporary address of the MH (4b).
(5) MH Location Information - When the home PFS receives the next
packet destined for the home address of the MH, if the MH is
available for autonomous mode communication, the home PFS sends
an "MH Location Information" message to the sender. At the same
time, it forwards the packet to the current temporary address of
the MH. When the sender receives the "MH Location Information"
message, it updates the cache entry of the MH's location and
enters autonomous mode. This step takes place only if preceded
by step(4b).
5 Internet Packet Transmission Protocol(IPTP)
In this Section we describe the Internet Packet Transmission
Protocol(IPTP). IPTP consists of four packet types that fit within
one packet format. The packet types provide packet forwarding, new
address notification, pinging for an autonomous supporter, and an
IPTP echo check.
5.1 Message Type
In this subsection, we describe the different IPTP message types.
The parameter types are defined in detail in Section 5.2.
(1) Packet Transmission
This message is used to forward packets from a PFS to an MH and
to send packets from an SH to an MH. It does not require a
response.
The following parameters should be set:
- Type
- Aim
- Counter
- Home address of MH
- Temporary address of MH
- Encapsulated packet
(2) MH Location Information
This message is used to notify a PFS or an SH of an MH's new
address. It requires a response.
The following parameters should be set:
- Type
- Aim
Expires 2 January 1994 [Page 15]
Internet-Draft Packet Forwarding July 1993
- Sequence
- Autonomous
- Home address of MH
- Temporary address of MH
- Address of PFS: See Section 5.2.
- Authentication information
The following parameters should be set in a response:
- Type
- Aim
- Sequence
- Status
(3) Ping Autonomous Supporter message
This message is used for an MH to find a PFS which supports the
autonomous mode in a new temporary network. This message
requires a response.
The following parameters should be set in a request message:
- Type
- Aim
- Sequence
- Home address of MH
- Temporary address of MH
- Authentication information
The following parameters should be set in a response message:
- Type
- Aim
- Sequence
- Autonomous
- Status
(4) Echo message
This message is used to examine whether a host employs IPTP or
not. It requires a response.
The Following parameters should be set in both a request and a
response:
- Type
- Aim
- Sequence
5.2 Parameters
Type:
This field indicates a message type of an IPTP packet.
Expires 2 January 1994 [Page 16]
Internet-Draft Packet Forwarding July 1993
Value : Meaning
--------------------------------------------
0 : Packet Transmission message
1 : MH Location Information message
2 : Ping Autonomous Supporter message
3 : Echo message
Aim:
This field indicates whether the packet contains either a
request or a response. Each message except "Packet
Transmission" message requires a response.
Value : Meaning
----------------------------------------------------
0 : neither request nor response
(That is "Packet Transmission" message.)
1 : request
2 : response
Sequence number:
The sequence number of the packet between a requester and a
responder. It is used to indicate the relationship between a
request and a response packet.
Autonomous:
Used only on "MH Location Information" messages from an MH to
the home PFS. It indicates whether the home PFS should
notify SHs of the MH's temporary address or not.
Value : Meaning
-------------------------------------------------------
0 : The home PFS must not notify SHs of the MH's
temporary address,
1 : The home PFS may notify SHs of the MH's
temporary address.
Counter:
The counter is used to detect forwarding loops. It is set to
an implementation-specific number whenever a "Packet
Transmission" message originates. When a PFS receives the
"Packet Transmission" message, the PFS decrements the counter
by 1. If the counter is equal to 0, the PFS discards the
packet instead of forwarding it.
Expires 2 January 1994 [Page 17]
Internet-Draft Packet Forwarding July 1993
Status:
The status of the packet.
Value : Meaning
--------------------------------------------
0 : No problem
1 : Authentication error
2 : Specified MH's address is unknown
Home address of MH:
The address of an MH on its home network.
Temporary address of MH:
The address of an MH on a temporary network. Assigned using
some dynamic configuration protocol such as DHCP.
Address of PFS:
The IP address of a PFS. Possible values are:
Situation : Meaning
--------------------------------------------------
1. MH migrates to new : Address of PFS which
network is an autonomous supporter
2. PFS notifies Auto. : Address of home PFS
mode supporter
Authentication information:
A password or token that PFSs use to decide whether an MH has
sufficient credentials to be given service. The exact nature
of this is beyond the current scope of this document. To
allow for multiple types of authentication information, the
following format should be obeyed. Multiple authentication
fields may be present to accommodate a variety of
authentication mechanisms.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Version | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-...
The Authentication Type field describes which authentication
mechanism is being used, with the Version field detailing
which version of that mechanism. The Length field indicates
the length of the authentication data in octets.
Authentication Type 0 is just padding, and as such, only the
type field is used (i.e., it is just a 0-filled octet).
Expires 2 January 1994 [Page 18]
Internet-Draft Packet Forwarding July 1993
Authentication Type 1 indicates that the authentication data
are just a plaintext password; Version is 0; the Length field
indicates the length of the password, and the authentication
data is a cleartext password.
This type of authentication should only be used
when the physical medium can be trusted.
Authentication Types 2-127 are reserved for future standard
definitions.
Authentication Types 128-255 are reserved for future
definition by vendors and/or implementors.
Encapsulated packet:
This is an original IP packet destined for MH. This field is
only included in "Packet Transmission" messages.
Optional data:
This is a field for optional data.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | optional data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
5.3 Packet Format
(1) Packet Transmission message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | aim | (not used) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (not used) | counter | (not used) | (not used) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| home address of MH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| temporary address of MH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (not used) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| encapsulated packet
+-+-+-+-+-+-+-+-+-+-+-+-+-...
(2) MH Location Information message
Expires 2 January 1994 [Page 19]
Internet-Draft Packet Forwarding July 1993
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | aim | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| autonomous | (not used) | status | (not used) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| home address of MH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| temporary address of MH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| address of PFS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| authentication information
+-+-+-+-+-+-+-+-+-+-+-+-+-...
(3) Ping Autonomous Supporter message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | aim | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| autonomous | (not used) | status | (not used) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| home address of MH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| temporary address of MH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (not used) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| authentication information
+-+-+-+-+-+-+-+-+-+-+-+-+-...
(4) Echo message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | aim | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| autonomous | counter | status | (not used) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional data
+-+-+-+-+-+-+-+-+-+-+-+-+-...
Expires 2 January 1994 [Page 20]
Internet-Draft Packet Forwarding July 1993
5.4 State Diagrams
+------------+
| non-mobile |
+------------------>| mode |
| migrate to +------------+
| home network | migrate to another network
| ------------- | -------------------------------
| v send a request to get a tmp adr
| +-------------+
+------------------>| waiting for |
| migrate to | tmp adr |
| another +-------------+
| network | get a tmp adr
| -------------- | -------------
| send a request v send MHLI
| to get a tmp +-------------+
| adr | waiting for |
| | MHLI ack |
| +-------------+
| | receive MHLI ack
| PT | ----------------
| -- | send PAS
| +-----+ | +-------+
| v | v v | PT
| +------------+ | +-------------+ | --
| | forwarding |--+ | waiting for |----+
+--| mode |<----| PAS ack |
^ +------------+ +-------------+
| timeout | receive PAS ack
| ------- | ---------------
| |
| | +-------+
| v v | PT
| +-------------+ | -- PT : Packet Transmission
+-------------------| autonomous |----+ MHLI : MH Location Info.
migrate | mode | PAS : Ping Auto. Supporter
------- +-------------+
Figure 9. State Diagram of an MH
Expires 2 January 1994 [Page 21]
Internet-Draft Packet Forwarding July 1993
+------------+
| forwarding |
| mode |
+------------+
receive MHLI ^ | receive MHLI
without MH's address | | ------------
---------------------- | |
| v
+-------------+
| autonomous |
| mode |<-+ send a packet to MH
+-------------+ | -------------------
| | send PT
+----+
Figure 10. State Diagram of an SH
Expires 2 January 1994 [Page 22]
Internet-Draft Packet Forwarding July 1993
+------------+
| waiting for|<------------------------------+
| MHLI ack | |
+------------+ |
| ^ receive MHLI |
receive MHLI ack | | without Autonomous |
---------------- | | -------------------- |
| | update address table |
| | |
receive MHLI | | +-----+ receive a normal packet |
with Autonomous v | v | for the home MH |
-------------------- +------------+ | ------------------------ |
update address table | forwarding |---+ send PT |
+----------------------| mode | |
| +------------+ |
| migrate to home network | ^ receive MHLI |
| (receive MHLI) | | without Autonomous |
| ----------------------- | | --------------------------------- |
| replace ARP entry for | | update address table |
| the home MH | | replace ARP entry for the home MH |
| send MHLI ack v | send MHLI ack |
| +------------+ |
| | initial | |
| | state | |
| +------------+ |
| migrate to home network ^ | receive MHLI |
| (receive MHLI) | | with Autonomous |
| ----------------------- | | --------------------------------- |
| replace ARP entry for | | update address table |
| the home MH | | replace ARP entry for the home MH |
| send MHLI ack | v send MHLI ack |
| +-------------+ |
| | autonomous |------------------------------+
| +--------------------| mode | receive MHLI without Autonomous
| | +-------------+ -------------------------------
| | receive MHLI ack ^ | update address table
| | ---------------- | | send MHLI to previous PFS
| | | |
| |receive MHLI | | receive a normal packet
| | without Autonomous | | for the home MH
| |-------------------- | | -----------------------
| |update address table | | send PT
| |send MHLI to | v send MHLI to sender
| | previous PFS +------------+
| +------------------->| waiting for|
+--------------------->| MHLI ack |
+------------+
Figure 11. State Diagram of a home PFS
Expires 2 January 1994 [Page 23]
Internet-Draft Packet Forwarding July 1993
+---------------+
| waiting for |
| MHLI ack |
+---------------+
| ^
| | receive PT
receive MHLI ack | | --------------------------------
---------------- | | forward it to home adr (send PT)
| | send MHLI without MH's address
v |
+---------------+
| forwarding to |
| home adr mode |----------+
|(initial state)| |
+---------------+ |
^ | |
receive MHLI | | receive PAS | receive MHLI
without MH's adr | | ------------ | -------------
------------------ | | send PAS ack | send MHLI ack
send MHLI ack | | |
| v |
+-------------+ |
| forwarding |<-----------+
| mode |<------+ receive MHLI
+-------------+ | -------------
^ | | | send MHLI ack
| | +---------+
| |
receive MHLI ack | | receive PT
---------------- | | ------------------------------------
| | forward it to new location (send PT)
| | send MHLI
| v
+---------------+
| waiting for |
| MHLI ack |
+---------------+
Figure 12. State Diagram of an Autonomous Supporter
(a PFS for visitor MHs)
Expires 2 January 1994 [Page 24]
Internet-Draft Packet Forwarding July 1993
5.5 Packet Transmission Parameters
Two important transmission parameters for IPTP are the timeout
interval and the retransmission count. The timeout interval is the
length of time IPTP will wait before retransmitting a packet. The
retransmission count is the number of times a packet will be resent.
IPTP defines these parameters for all messages except "Packet
Transmission" messages. IPTP "Packet Transmission" messages can be
lost without a loss of correctness because IP makes no guarantee
about reliable packet delivery. Reliable delivery is left to higher
level protocols in the transport and network layers. For the other
message types, we assume that the timeout interval will be tuned to
specific implementations. The remaining issue, therefore, is the
number of retransmissions.
The "MH Location Information" message should be retransmitted an
infinite number of times. If for any reason, such as a network
failure, an MH cannot notify its home PFS of its new address the MH
will become temporarily lost. Continuous retransmission guarantees
that the time of the network partition will never exceed the
transmission of the last "MH Location Information" message. If
communication between the MH and PFS is ever possible again, then a
packet will eventually get through, allowing hosts communicating
with the MH to reestablish contact through the home PFS.
The other packet types, "Ping Autonomous Supporter",
and "Echo", should be retransmitted only a finite number of times.
Loss of these packets may result in a less efficient routing, but
will not be fatal. For instance, a host capable of autonomous mode
communication may mistakenly use forwarding mode if a "Ping"
message is lost.
6 Implementation Notes
6.1 Translation Tables
Address Translation tables are maintained by PFSs, and by SHs and MHs
using autonomous mode. All table entries contain the home address
and the current temporary address of a MH. In addition, table
entries in a home PFS will contain the address of the PFS in the MH's
current temporary network. Table entries in SHs and MHs will contain
the address of the MH's home PFS.
PFSs are responsible for providing non-volatile storage for
translation information. SH and MH tables are only caches for data
managed by PFSs. An SH or an MH can easily refresh its tables by
interacting with the appropriate PFS. Of course, a disasterous
failure might cause a PFS to lose its translation information. If
this occurs, the information must be recovered by inducing MHs to
Expires 2 January 1994 [Page 25]
Internet-Draft Packet Forwarding July 1993
resend "MH Location Information" messages.
6.2 Avoiding Redundant "MH Location Information" Messages
In an environment where both forwarding mode and autonomous mode are
utilized, a PFS might send unnecessary "MH Location Information"
messages to SHs using forwarding mode. Because they are using
forwarding mode, these SHs will ignore the "MH Location Information"
messages. Packets from the SH to the MH will continue to be sent to
the PFS, resulting in the generation of ineffective and unnecessary
"MH Location Information" messages.
To avoid this, a PFS should keep a list of hosts it serves that are
using forwarding mode. The PFS can then refrain from sending "MH
Location Information" messages to any host on this list. Hosts can
be added to this list when the first "MH Location Information"
message cannot be delivered to the SH. The failure can be detected
either by an ICMP message that indicating that the destination port
is unreachable or when the SH fails to acknowledge the "MH Location
Information" message.
6.3 PFS Packet Interception
In order to correctly forward packets for mobile hosts, a PFS must be
able to intercept packets addressed to hosts that have migrated away
from the local network. One possible implementation is to use
promiscuous mode, if the the underlying interface supports it. Such
a solution, however, may impose a substantial load as the PFS is
forced to inspect every packet.
A more attractive alternative is to use a proxy ARP. When a PFS
receives a "MH Location Information" message from an MH, it
broadcasts an ARP reply packet for the MH's home address. The reply
packet specifies that the MH's IP address now resolves to the address
of the PFS's physical interface. Subsequent packets addressed to the
MH's home address will be received by the PFS.
If a PFS is already forwarding packets for an MH, it responds as a
proxy to any ARP requests for the MH's address. The ARP reply
message indicates that packets destined for the home (IP) address
of the MH should be physically (i.e. at the hardware address level)
addressed to the PFS.
Unfortunately, because of the need to reuse temporary IP addresses,
this technique cannot be applied to a PFS acting as an autonomous
supporter for a visiting MH. A visiting MH will use a temporary
address. This address will eventually be reused when the visiting
MH migrates to a new network. If the PFS issues a Proxy ARP for
this address, packets intended for the new user of the address
Expires 2 January 1994 [Page 26]
Internet-Draft Packet Forwarding July 1993
might be lost. Temporary addresses must be reusable because of the
limited number of address bits available. The consequence is that
a PFS may only act as an autonomous supporter if it has a
promiscuous interface on a broadcast medium that allows it to see
all network traffic.
6.4 Adaptive Mode Selection
An MH that transmits a "Ping Autonomous Supporter" message may have
to wait some time for a local PFS to reply. This delay is passed to
applications as additional latency introduced by MH migration. To
avoid this problem, the MH may send the "MH Location Information" to
the home PFS without the Autonomous flag set. After the MH finds a
PFS which supports autonomous mode, it may resend "MH Location
Information" message, this time with the Autonomous flag set.
6.5 Detection of Forwarding Loops
If an MH is roaming among temporary networks where PFSs support
autonomous mode, it is possible that forwarding relays will occur.
To prevent a forwarding loop, the "Packet Forwarding" message
contains a special counter.
When a PFS forwards a packet for the first time,
it sets the counter to an upper bound defined by the system. Before
another PFS forwards the packet, it decrements the counter by 1 and
it checks to see if the the value is zero. If the PFS finds the
counter equal to zero, the packet is discarded. Otherwise the packet
is forwarded normally.
6.6 Gateway Packet Filters
For security reasons, some gateways filter packets based on port
numbers. Because an original packet is encapsulated in an IPTP
packet in our approach, the gateways will check the IPTP port number.
Such gateways will fail to filter out packets that might otherwise be
objectionable because the packet filters do not see within the IPTP
packet. Similarly, a filter applied to IPTP will remove all
encapsulated packets, regardless of how the local system
administrator feels about them.
If the gateway host filters packets of specified port numbers and
IPTP port number itself is not included in the port number list for
filtering, the IPTP packet will pass through, even if the original
packet in the IPTP packet should be filtered. On the other hand, if
the gateway host makes packets of specified port numbers pass through
and IPTP port number is not included in the list for passing, the
IPTP packet will be filtered.
One way to solve this problem is to redesign the IPTP packet format.
Expires 2 January 1994 [Page 27]
Internet-Draft Packet Forwarding July 1993
"Packet Transmission" messages could reflect the packet type in a
newly defined IP option field rather than be indicated in the port
number field.
6.7 Handling IP options
When a PFS encapsulates a packet, it should copy IP options of the
packet to the encapsulated packet. When an MH decapsulates the
packet, it should restore IP options of the packet to the original
packet.
7 Acknowledgement
The description of authentication is almost fully derived from
Columbia University's draft "Protocols for Supporting Mobile IP
Hosts"[3] and IBM's draft "Support for Mobility with Connectionless
Network Layer Protocols(Transport Layer Transparency)"[4].
8 Authors' Addresses
Hiromi Wada
Information Systems Research Laboratory
Matsushita Electric Industrial Co., Ltd.
1006 Kadoma, Kadoma-shi, Osaka, 571 JAPAN
Internet : hwada@isl.mei.co.jp
Phone : +81-6-906-2431
Fax : +81-6-906-5547
Tatsuya Ohnishi
Information Systems Research Laboratory
Matsushita Electric Industrial Co., Ltd.
1006 Kadoma, Kadoma-shi, Osaka, 571 JAPAN
Internet : ohnishi@isl.mei.co.jp
Phone : +81-6-906-2431
Fax : +81-6-906-5547
Brian Marsh
Matsushita Information Technology Laboratory
182 Nassau St, 3rd floor
Princeton, NJ 08542
Internet : marsh@mitl.com
Expires 2 January 1994 [Page 28]
Internet-Draft Packet Forwarding July 1993
References
1. H.Wada, T.Yozawa, T.Ohnishi, and Y.Tanaka, "Mobile Computing
Environment Based on Internet Packet Forwarding", 1993 Winter USENIX
2. R.Droms, "Dynamic Host Configuration Protocol", Internet Engineering
Task Force, INTERNET-DRAFT, November 1992
3. J.Ioannidis, D.Duchamp, G.Q.Maguire Jr, and S.Deering, "Protocols for
Supporting Mobile IP Hosts", Internet Engineering Task Force,
INTERNET-DRAFT, June 1992
4. C.Perkins and Y.Rekhter, "Support for Mobility with Connectionless
Network Layer Protocols(Transport Layer Transparency)", Internet
Engineering Task Force, INTERNET-DRAFT, January 1993
5. F.Teraoka, "VIP:IP Extentions for Host Migration Transparency",
Internet Engineering Task Force, INTERNET-DRAFT, Novenber 1992
Expires 2 January 1994 [Page 29]
Internet-Draft Packet Forwarding July 1993
TABLE OF CONTENTS
1 Introduction 1
1.1 Goals 2
1.2 Basic Concept 2
1.3 Overview 3
2 Addressing 3
3 Packet Forwarding 4
3.1 Forwarding Mode 4
3.2 Autonomous Mode 5
3.2.1 SH Transmission 6
3.2.2 Autonomous Supporter Transmission 7
4 Location Information Management 8
4.1 MH Migration/PFS Notification 8
4.2 Autonomous Sender Notification 10
4.2.1 Packets to the Home Address 10
4.2.2 Packets from an AS 11
4.2.3 Packets from a Migrated MH 12
4.3 Packets to an Obsolete Temporary Address 13
5 Internet Packet Transmission Protocol(IPTP) 15
5.1 Message Type 15
5.2 Parameters 16
5.3 Packet Format 19
5.4 State Diagrams 21
5.5 Packet Transmission Parameters 25
6 Implementation Notes 25
6.1 Translation Tables 25
6.2 Avoiding Redundant "MH Location Information" Messages 26
6.3 PFS Packet Interception 26
6.4 Adaptive Mode Selection 27
6.5 Detection of Forwarding Loops 27
6.6 Gateway Packet Filters 27
6.7 Handling IP options 28
7 Acknowledgement 28
8 Authors' Addresses 28
Expires 2 January 1994 [Page i]
Internet-Draft Packet Forwarding July 1993
FIGURES
Figure 1. Forwarding Mode 5
Figure 2. Autonomous Mode 6
Figure 3. Forwarding mode by an autonomous supporter PFS 7
Figure 4. Location information distribution 9
Figure 5. Packets to the Home Address 11
Figure 6. Packets from an AS 12
Figure 7. Packets from a Migrated MH 13
Figure 8. Packets to an Obsolete Temporary Address 14
Figure 9. State diagram of an MH 21
Figure 10. State diagram of an SH 23
Figure 11. State diagram of a home PFS 23
Figure 12. State diagram of an Autonomous Supporter 24
Expires 2 January 1994 [Page ii]